1. Field of the Invention
The present invention relates to the field of distributed software applications, and more particularly to a system and method for coordinating access to data in a distributed computer system.
2. Description of the Related Art
In the software arts, the problem of coordinating multiple threads or processes to share data or resources often arises. For example, when one process or thread is writing to data, other processes or threads may need to be prevented from writing to the same data at the same time in order to prevent data errors from occurring. Also, processes or threads may need to be prevented from reading from the data while it is being written to, in order to ensure that partial or incorrect data is not read.
Another aspect of coordinating the execution of multiple threads or processes pertains to forcing a series of operations to be performed atomically. For example, consider an application where one process updates a static data structure containing X and Y coordinates for items to be displayed by another process. If the update process alters the X coordinate for an item and is preempted before it can change the Y coordinate, the display process attempt to display the item before the Y coordinate is updated, resulting in the item being displayed at the wrong location.
Various types of “synchronization objects” have been used in synchronizing execution among multiple threads. For example, one type of synchronization object is a mutex. A mutex (short for mutual exclusion) may be used to guarantee exclusive access to shared data or a shared resource, typically by controlling access to the data or resource through “lock” and “unlock” operations. For example, a first thread may lock (acquire) a mutex indicating that the corresponding data or resource is in use before performing an update. The first thread may then unlock (release) the mutex after the data or resource has been updated. Any other threads must wait for the mutex to be unlocked before updating the data or resource. This technique of waiting for a mutex is often called “blocking” on a mutex because the thread is blocked and cannot continue until the mutex is released. Other types of synchronization objects known in the prior art include semaphores and queues.
Programmers often find it difficult to properly implement execution synchronization using synchronization objects. One reason for this is that the programmer is typically responsible for coding and managing execution synchronization at a relatively low level. This responsibility may include: properly releasing synchronization objects; defining and implementing timeout behavior when waiting to acquire a synchronization object; etc. In a complex application, this can require a significant amount of detailed work on the part of the programmer and can be difficult to accomplish.
Thus, execution synchronization can be difficult to implement correctly and serious problems can arise when not implemented correctly. Therefore, an improved system and method for synchronizing execution of software activities is desired. It would be desirable for the improved system and method to simplify the task of implementing execution synchronization for an application. In particular, it would be desirable to abstract this task so that the programmer can work at a more intuitive level, e.g., using an application programming interface (API) to perform the synchronization.
In addition, various systems may not provide a solution for coordinating access to distributed data in a highly distributed environment with multiple processes and threads accessing the distributed data. For example, consider the problem of a distributed application implemented over a cluster of application servers, such as a large-scale web application. It would be desirable to provide a system and method for coordinating access to distributed data for such an application. It would also be desirable for the system and method to ensure that that the coordination works smoothly even in the case of process, machine, or network failure.